DASH Dynamic adaptive streaming over HTTP is intended to support a media streaming model for delivery of media content. DASH provides streaming technique, which adapts the provision of media stream to the currently available link bitrates as disclosed in “Dynamic adaptive streaming over HTTP (DASH)—Part 1: Media presentation description and segment formats”, ISO/IEC 23009-1:2012(E), Version 2.1c2. DASH is designed as a client controlled adaptive HTTP streaming protocol. That means, that the server describes a set of available media qualities for example as a manifest file being provided to the users and the user selects depending on the available link bitrate a media representation matching the current link bitrate. Apple HTTP Live Streaming (HLS) is another example of adaptive streaming technique.
Multicast Broadcast Multimedia service MBMS as defined in 3GPP TS 26.246 version 12.0.0 “Multimedia Broadcast/Multicast Service (MBMS); Architecture and functional description” (2013-12) is a point-to-multipoint service in which data is transmitted from a single source entity to multiple recipients. Transmitting the same data to multiple recipients allows network resources to be shared. MBMS is especially applicable, when many users in a cell or any broadcast area use the same stream quality. For example in urban areas the same service may be simultaneously offered to a number of users with a higher bitrate then in sub-urban areas.
MBMS download delivery method uses FLUTE protocol when delivering DASH-formatted content over MBMS bearers. The FLUTE protocol (RFC 3926) is used for file delivery over UDP. The FLUTE protocol is selected by MBMS, DVB-H IP Datacast and OMA Mobile Broadcast Services as file delivery protocol. FLUTE in the Broadcast Multicast Server (BM-SC) cares about partitioning a media file into a sequence of media segments, namely UDP packets. Thus, FLUTE is a protocol, which allows delivery of files, like DASH files over broadcast using UDP as a transport protocol.
FLUTE is built on top of the Asynchronous Layered Coding (ALC) protocol. ALC is intended to transmit one or more transmission objects to multiple receivers. Each object is uniquely identified by a LCT Transport Object Identifier (TOI). ALC is carried using UDP over IP packets. Every IP packet, which is generated by partitioning of a data file carries the TOI value in the packet header.
FLUTE adds the needed mechanism of associating HTTP like metadata such as a Content-Location and Content-Type to an LCT Transmission Object. In particular, FLUTE defines the so-called File Delivery Table (FDT), which is basically a list containing an association of file metadata to the TOIs. The client maintains the FDT and the sender can add entries by using FDT Instances, which are sent as Transmission Objects. In particular in FLUTE, the FDT Instance carries among other parameters a File Delivery Descriptor which contains file properties such as File Name, Content Location and File-Type and also an expiry timestamp or timer or time. Further the FDT table provides an association between the File Delivery Descriptor, the TOI and the expiry time. The expiry value is given as absolute NTP timestamp. Since each FLUTE receiver maintains the FDT, the purpose of sending FDT Instance is to update or extend the File Delivery Table at the receiver. The FDT Instance expiry time, “expires”, determines the expiry of the TOI to File Descriptor association or in other words the expiry of the FDT instance.
Each FLUTE receiver maintains the File Delivery Table (FDT), which is depicted as example in FIG. 2. Thus according to FIG. 2 an object or in this case a file has an assigned TOI, first column. The second column, called “expires” states when a particular file, for example with the TOI 5 expires, here at time A. The column “Content Location” provides an URL, where the content is located and may be fetched. The Content-MD5 may be used to differentiate different versions of the same file. According to FIG. 2, files with TOI 5 and 6 have the same expiry time A and with TOI 9 and 10 the same expiry time B. Thus, the sender (BM-SC) defines the expiry of the TOI to File Delivery Descriptor association with an absolute NTP timestamp with one timestamp for one or more files as depicted in FIG. 2.
According to the MBMS Specification TS 26.346 V12.0.0 (2013-12) “Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs”, the FDT expiry mechanism is used to indicate the end of transmission time for a certain object or a data file.
The problem with the existing solution is that the provided expiry time does not consider the characteristics of a transmission, like a transmission delay. The transmission delay depends on various network components including radio parameters. For example, the end to end delay between the BM-SC down to the UE depends on how certain parameters have been configured on an eNodeB. If all eNodeB have good and fast backhaul connection then the transmission delay is expected to be small. The speed of the eNodeB hardware as well as the buffering has also impact on the end-to-end delay. Further also the speed of the BM-SC hardware impacts the end-to-end system. For this reason the end-to-end delay can largely differ between systems and this leads also to varying transmission time of a data file.
Further, any sort of communication is prone to packet losses. The sender cannot influence which packet gets lost. It might be the first, or a burst at the beginning of a transmission. Consequently data packets carrying the FDT table information (i.e. FDT Instance objects) may get lost or corrupted. Packets may be sent on purpose out of sequence.
Further, the receiver needs to be precisely time synchronized when getting an absolute expiry time. Today's phones are only loosely synchronized. If the network supports the Network Time & Zone solution (NITZ), then a timestamp is only provided at phone restart. Consequence is that many phones are several seconds off. NITZ is not designed to provide sub-second precision.
DASH operates by segmenting continuous media content stream into a sequence of media segments at a server side. Further a media segment, like the DASH media segment is typically subdivided into multiple data packets, UDP data packets, wherein the data packets have a roughly constant duration of time, the so called data packet duration. Each data packet is uniquely marked with a sequence number, so that the client can re-assemble the file. For the MBMS broadcast, a media segment is partitioned into multiple FLUTE/UDP packets. Optionally, FEC redundancy is calculated and added as overhead (i.e. additional packets containing redundant data) to the transmission of a data file. A data file server, like the BM-SC performs the generation of the UDP data packets by partitioning the media segments and calculating the FEC redundancy. The segmentation is performed by a Live Encoder LE, wherein a LE comprises a Segmenter and may comprise an Encoder. However the data files as generated by the LE have different sizes in the sense that they comprise a different number of data packets, and therefore the data packets have only a roughly constant duration. The LEs are namely vendor specific. Each live encoder vendor has its own algorithms to increase compression efficiency while keeping a certain end-to-end delay. In case of broadcast the generated media segments are on average 100 kByte size, some are larger, e.g. up to 130 kByte and some are smaller, e.g. up to 70 kByte, then as mentioned when generating media segments, each segment might have a different number of UDP data packets. Thus, the segment sizes are different.
Further for broadcast transmission typically a constant bitrate bearer on a transmission link is provided. For example, MBMS for LTE (eMBMS) offers a Constant Bitrate Broadcast Bearer Service. The bitrate is defined though the GBR (Guarantees Bitrate). Thus, in case of broadcast there is a constant bitrate bearer allocated for broadcast transmission. For example the allocated bitrate might be 1 Mbps that means that it takes 0.5 sec for a segment of size 500 kb to be transmitted and a segment of size 1500 kb needs 1.5 sec. However since the segment sizes may have different sizes, consequently time for transmission over a constant bitrate may differ.
Therefore on one side different data file sizes are generated, so that the transmission of the data files via a network takes respectively different time duration and on the other side due to the varying end-to-end delay in the network, the variation of the transmission of a data file in time is intensified, so that the static set expiry time at the server side may not provide an accurate end of transmission time point.
Furthermore, the existing FLUTE expiry mechanism does not work with a static File Delivery Descriptor tables. The idea of the static file delivery descriptors is to avoid sending the FLUTE FDT Instances. Thus, the required information are sent at the beginning of a session and no updates are sent afterwards.
The key idea of this static file descriptor tables is, that the filenames of adaptive bitrate streaming segments (like DASH or HLS) contain a running index. This index is typically increased by one. Since the TOI is also a unique index, the idea is to provide all static information of the File Descriptors, in form of a template, so that the client can derive the filename by combining the TOI with a basic filename template.
FIG. 3 depicts that principle. On the left side a sequence of Input files with the URL address and a running index (here from 9 to 13) is provided. The filename can be expressed by a template (right side), where the format tag % d is replaced by the value of the TOI from the transport.
With the template form, the URL is constructed by replacing a certain part of the template by the index TOI. A template form may have the form in C printf format: http://( . . . )/seg_% d.3gs
where % d is replaced by the value of TOI to result in the URL to be used for requesting the subsequent media segments
The problem with the way of avoiding the FDT Instance fields and providing the File Descriptors as a static File Delivery Descriptor Table is the missing provision of the expiry time for the TOI association. However, the intention of the expiry mechanism is to allow the re-use of the TOI value for another file transmission.
Moreover, the user needs to have an expiry time as a trigger for an effective managing of its memory. In particular, from a client memory management perspective, the user should be able to decide when to delete the received data packet of a data file.